home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / ARMLINUX / MAIL / 9707 / 000009_owner-linux-arm…r.rutgers.edu _Wed Jul 2 18:54:17 1997.msg < prev    next >
Internet Message Format  |  1997-11-30  |  2KB
  1. Return-Path: <owner-linux-arm-outgoing@vger.rutgers.edu>
  2. Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id SAA16640 for <willy@odie.fluff.org>; Wed, 2 Jul 1997 18:54:17 +0100
  3. Received: from root@vger.rutgers.edu (port 11569 [128.6.190.2]) by nic.funet.fi with ESMTP id <15971-19265>; Wed, 2 Jul 1997 20:53:14 +0300
  4. Received: by vger.rutgers.edu id <1000376-30851>; Wed, 2 Jul 1997 13:50:22 -0400
  5. Received: from IDENT-NOT-QUERIED@odie.barnet.ac.uk (port 2010 [194.82.202.98]) by vger.rutgers.edu with ESMTP id <1000375-30852>; Wed, 2 Jul 1997 13:50:06 -0400
  6. Received: (from willy@localhost) by odie.barnet.ac.uk (8.8.2/8.8.0) id SAA16614; Wed, 2 Jul 1997 18:51:17 +0100
  7. From: Matthew Wilcox <willy@odie.barnet.ac.uk>
  8. Message-Id: <199707021751.SAA16614@odie.barnet.ac.uk>
  9. Subject: Re: Re ELF
  10. To: charlese@cvs.com.au (Charles Esson)
  11. Date:     Wed, 2 Jul 1997 18:51:16 +0100 (BST)
  12. Cc: linux-arm@vger.rutgers.edu
  13. In-Reply-To: <33B9A606.6A2B@cvs.com.au> from "Charles Esson" at Jul 2, 97 10:51:18 am
  14. X-Mailer: ELM [version 2.4 PL25]
  15. MIME-Version: 1.0
  16. Content-Type: text/plain; charset=US-ASCII
  17. Content-Transfer-Encoding: 7bit
  18. Sender: owner-linux-arm@vger.rutgers.edu
  19. Precedence: bulk
  20. Status: RO
  21.  
  22. > 1) Does anyone know where one gets the ELF standard.
  23.  
  24. No.  Sorry.  Try a web search in altavista.
  25.  
  26. > 2) I could be barking up the wrong tree but: 
  27. > a) The strong ARM cache uses virtual addresses. 
  28. > b) To flush the write cache we have to read data from an uncached area,
  29. > 16k of it.
  30.  
  31. No.  To flush the instruction and data cache, the recommended method is to
  32. read 32kB.  
  33.  
  34. > I don't think a task switch should involve cleaning up a 16k cache, if
  35. > it does performance will be pretty poor.
  36.  
  37. It isn't /that/ bad.  Other CPUs manage that, and considerably worse.  The
  38. problem is exacerbated by the RPCs slow memory bus, but it's still
  39. liveable with and it's considerably better than your alternative
  40. suggestion.
  41.  
  42. > If we map all processes into one virtual address space and under no
  43. > circumstances we map physical space into the virtual space twice then
  44. > the cache will never have to be flushed. This I see as a must.
  45.  
  46. This I see as a very bad idea.  It would mean all sorts of stupid
  47. restrictions on applications that don't exist under any other
  48. architecture.  You'd be limited to about 64MB per application and 48 tasks
  49. running simultaneously.  This is crap.